Prior art methods for merging work in progress with checked-in changes require numerous steps and a great deal of complexity in order to take into account the myriad details involved in the type of object model being merged. Such methods vary from one type of model to another. For example, Unified Modeling Language (UML) models require different steps than Metaobject Facility (MOF) models.
Information stored in an object-oriented repository often consists of large composite objects containing other composite objects. For example, a body of information expressed using UML consists of a model containing various detailed model elements and any number of packages. Each package can further contain various detailed model elements as well as additional packages.
In addition to the composite relationships within the model, there are many relationships between elements, and these relationships commonly cross package boundaries. For example, an attribute of a classifier in one package can have a type in another package. Or a generalization can refer to a supertype in a different package. For this reason, when a user wants to modify a single package using a UML modeling tool, he loads the entire model containing the package into the tool. This allows him to see and modify references in the package to elements outside the package.
The problem arises for a repository providing the ability for separate users to check out different packages within the same model. When multiple users check packages in and out of the same model at different points in time, the need sometimes arises for a user with a checked-out package to synchronize his work in progress with changes in other packages that were checked in after he checked out his package. He must do so in order to account for changes in the surrounding packages.
An example scenario could be as follows. Users X and Y are developing a model M, which contains packages P1 and P2. User X checks out package P1 and loads model M into his modeling tool. User Y checks out package P2 and loads model M into his modeling tool. Users X and Y change packages P1 and P2, respectively. User Y checks in his changes to package P2, which include a new class called C. User X needs to use class C in order to complete his changes to package P1. User X must merge his work in progress with the model changes user Y has checked into the repository. User X cannot yet check in changes made to his package P1 because they are incomplete and inconsistent. Moreover, he cannot complete his work and make package P1 consistent until he can merge the new package P2 into the model in his tool.